I’ve spent the past 3 years as Digital Program Lead on a large, complex, digital modernisation program where I’ve learned a lot about digital product team organising and scaling and how to adapt the digital operating model as context changes. The below is a vastly summarised list of how we adjusted the model and some key lessons learned.
For this particular challenge the foundations of the operating model were based on:
Team Topologies - how to organise business and technology teams for fast flow - provides a coherent vocabulary and ways of working together across teams to achieve good software delivery.
Dual Track Agile - how to embed Design Thinking into each stream-aligned product/feature team - dual track ensures customer research led product development is part of each product teams work iteration.
This is how we organised and iterated over the phases
Proof of Concept (PoC) Phase: Separate Design/Discovery and Stream-alinged engineering team.
We had a single design-discovery team of Product and Ux Design folks who completed "just enough" customer research to design the core Customer Experience (Cx) and worked closely with the engineering teams on the domain driven design (DDD) to define the data model and bounded context (GraphQL API’s) for the PoC.
We had a single stream-aligned engineering team focussed on a small end to end flow of the core journey to test our assumpations around the architectiure, customer experience and to figure out the next stage team structure, while the Design/Discovery teams continued building out the next set of Cx flows.
Most Valuable Part (MVP) Phase: Merged Design/Discovery & Engineering to create stream-aligned feature teams running dual track Agile
Each stream-aligned feature team worked across a core domain area with a clear vision and purpose, with dual track ensuring tighter collaboration between Cx design and software design and development. And to ensure they had all skills required to go from idea to working software.
We also implemnented the following Team Topology teams:
1 x Complicated subsystem team: Enterprise data team handled event stream, queue and data replication to the Mainframe
1 x Enablement team: DevOps team to setup the initial CI/CD tooling and pipelines
1 x Enablement team: Observability team to setup App Insights alerting and monitoring
1 x Platform team: Cloud team for handing all network (Cloudflare) and cloud (Azure) Infrastructure
Continuous value delivery phase: Scaling to 120+ and 12 teams over 24 months
Stream-aligned: Increased from 2 to 6 feature teams as scope increased, we tackled new Cx journeys and domain areas, but also kept team size to below 12
Enblement team: We folded DevOps & Observability into a single DevObs team, as tooling matured and stream teams could take on more CI/CD, metrics, alerting and monitoring
Complicated subsystem team: Enterprise data team needed to incease in size to support 6 stream-aligned teams
Patform team: Cloud and network teams remained unchanged in support of the program
Here are some of the most important lessons learned
Team topologies is an engineering focussed framework for aligning teams to business processes and domains, there is not much mention about customer centricity and design thinking or how Designers fit into the model. So the application of Jeff Pattons Dual Track Agile within each stream-aligned team was a really good marriage. It meant that each stream-aligned product team used DesignThinking to bake customer research led product development into their ways of working.
Watch out for bottlenecks as you scale stream-aligned teams. We found the Enterprise data team (complicated subsystem) came under pressure to service so many feature-product teams. So stream teams took on more of the below the line API/data requirements once the subsystem team reached 12 people. We favoured this over creating more subsystem teams so that stream teams could own more of the E2E architecture without losing velocity.
Also watch out for team size, as certain Stream teams approached 12+ people we looked to split the teams into smaller pods, in some instances sharing some full stack roles like Product, Design & Delivery. Meant a bit more coordinatiuon for those 3 roles but still better than 20+ person teams across multiple timezones.
Treat the operating model as a product, with Team Leads & Execs as the product team. This meant we were always inspecting and adapting the model across the program to meet the shifting needs of the business, stakeholders and customers.
Our teams spanned IST, CET, Europe time zones, which made collaboration difficult at critical times. So we split teams into no more than 2 timezones and no less than 4 hours overlap. But only where we were able to ensure all full stack roles were present.
------
I’d love to hear your thoughts and experience working with either or both Dual Track Agile & Team Topologies?
Comments